Encryption of end-to-end communication is an increasingly important feature, particularly for wireless communication devices such as cellular phones and personal digital assistants (PDAs) to reduce the likelihood of eavesdropping. Encryption can be applied to voice (cellular interconnect or private call dispatch) as well as data. Using voice as an example, encryption algorithms typically employ a secret key that is used to encode voice on the source handset using an encryption algorithm. The coded voice stream can then be transmitted securely over a cellular communication system to a destination or target device. In order to decode the encrypted voice signal, the destination handset must use the same secret key that was used to encrypt the data and apply a decryption algorithm.
A classic problem in cryptography is securely sharing a secret key between two devices that can be miles or thousands of miles apart. Automatic Public Key (APK) exchange techniques are both a secure and convenient way to establish a secret key between two devices without transmitting the secret key in the clear over an insecure link. Diffie-Hellman and Elliptic Curve Cryptography are two well-known public-key algorithms that can be combined with protocols such as FNBDT (Future Narrow Band Digital Terminal) to implement APK systems. Although APK methods are convenient compared with alternatives such as manual key loaders, they are relatively slow as a result of being computationally intensive and because of the large keys needed for good security. To avoid this speed penalty, most secure devices use APK only to establish a symmetric (shared by both sides) traffic key and then revert to fast symmetric-key encryption algorithm such as DES or AES to encrypt and decrypt the traffic.
Because APK exchange is relatively slow on wireless devices, it noticeably delays call setup. Call set-up is the time elapsed between pressing the send or push-to-talk button and the call connecting with a secure traffic channel or a secure voice communication established. Excessive set-up time is particularly harmful to the user experience on dispatch calls which are bursty in nature and are adversely affected by even small set-up delays.
Cryptographic devices characteristically usually require a method of key exchange. Symmetric key systems in particular require the identical key to be present at both the transmitter and receiver. Modern cryptographic systems rely on advanced mathematical techniques to securely share these common keys by performing an exchange of messages between the two users. As noted above, the exchange of messages to obtain common encryption keys can be time consuming for the user to complete.
Modern cellular phones provide reasonably secure communications for most informal conversations and business purposes. However, for highly sensitive communications in areas such as government, legal, and some business applications, additional protection against eavesdropping is sometimes required. Highly secure voice communication on wireless networks typically requires that the conversation be encrypted over the communication link using various techniques, many of which are well known in the art. Furthermore, cryptographic communication devices are typically dual mode devices that are capable of both clear (non-encrypted) and secure (encrypted) communication. Existing dual-mode communication devices in this regard fail to indicate in advance of the communication as to which mode is desired.
Motorola's iDEN technology for example includes a popular feature known as the Call Alert that signals to a recipient or remote user that a private call (PTT) session is being requested. The Call Alert feature allows the remote user to initiate communication immediately or to wait before responding. In current devices, the call alert feature only supports alerting the remote user that a clear call is requested and does not include any type of indication that a secure call is desired. Furthermore, if a secure call is really desired using the existing non-secure alert function, the alert is sent to the remote user. The remote user does not know that the initiator desired a secure dispatch call, and the remote user will likely respond with a clear call. The remote user's response will usually necessitate that the initiator verbally communicate that a secure call is desired in a clear call, terminate the clear call, and then initiate a secure call. The typical sequence is an alert, followed by a clear communication exchange, followed by a secure communication exchange. This scenario is annoying for the user and an inefficient use of system resources when attempting to establish secure communications using a call alert function.